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ABSTRACT 

The  Theatre  Broadcast  System  is  a  DSTO  developed  Concept  Technology  Demonstator 
communications  system  comprising  a  high  data  rate  satellite  broadcast  capability 
matched  with  low/  medium  data  rate  request  channels.  The  system  has  the  potential  to 
enhance  the  effectiveness  of  data  dissemination  to  deployed  forces  in  a  cost  effective 
manner.  This  document  provides  an  overview  of  the  system  concept,  the  principles  of 
operation  and  details  of  the  initial  implementation. 


RELEASE  LIMITATION 

Approved  for  public  release 


DEPARTMENT  OF  DEFENCE 


DEFENCE  SCIENCE  l  TECHNOLOGY  ORGANISATION 


DSTO 


Published  by 


DSTO  Electronics  and  Surveillance  Research  Laboratory 
PO  Box  1500 

Salisbury  South  Australia  5108  Australia 

Telephone:  (08)82595555 
Fax:  (08)8259  6567 
©  Commomvealth  of  Australia  2000 
AR-011-480 
July  2000 


APPROVED  FOR  PUBLIC  RELEASE 


The  Theatre  Broadcast  System 


Executive  Summary 

The  Theatre  Broadcast  System  (TBS)  is  a  demonstration  high  bandwidth,  tactical 
information  delivery  system  developed  by  DSTO  Communications  Division.  It  is 
targeted  at  operations  on  the  forthcoming  Optus  Cl  satellite.  The  concept  consists  of 
uplinking  ADF  data,  and  both  audio  and  video  information,  from  an  injection  point. 
Users  in  the  field  receive  the  broadcast  using  a  half  metre  diameter  dish  connected  to  a 
compact  receive  suite  and  laptop  running  Windows  NT.  Low  bandwidth 
communications  may  be  used  to  request  information  to  be  broadcast.  User  interfaces 
consist  of  standard  PC  applications  such  as  web  browsers,  mail  clients,  in  addition  to 
any  specialised  applications  required  for  user  data  display.  The  receive  terminals  may 
be  operated  stand-alone  or  connected  to  a  local  area  network.  DSTO  has  engineered  a 
COTS-based  hardware  solution,  developed  an  extensive  software  architecture  and 
applied  military  grade  security. 
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1.  Introduction 

Recent  developments  in  satellite  TV  technology  have  made  high  bandwidth,  military 
information  delivery  systems  realisable  using  compact,  inexpensive,  consumer  devices. 
Commercial  broadcast  and  VS  AT  (Very  Small  Aperture  Terminals)  architectures  can  be  readily 
adapted  to  military  needs  provided  security  architectures  and  appropriate  software  can  be 
developed.  Such  systems  are  made  possible  by  new  generations  of  satellites  which  offer  the 
power  and  bandwidth  to  deliver  broadband  multimedia  to  receiver  dishes  as  small  as  eighteen 
inches  in  diameter.  Traditional  military  satellite  communications  systems  on  the  other  hand, 
are  often  expensive,  bulky,  depart  from  commercial  standards  and  require  extended  system 
design  and  fabrication  programs.  In  many  cases,  it  makes  sense  to  forego  traditional 
approaches  to  gain  the  benefits  of  the  latest  technology,  particularly  for  non-critical  and 
augmented  communications.  Indeed,  there  is  a  world  wide  trend  towards  the  use  of 
commercial-type  communications  to  support  military  forces.  Ruggedised  military  satellites 
incorporating  processing  transponders  and  beam  forming  antennas  mated  with  over 
dimensioned  receive  systems  and  spread  spectrum  receivers  can  be  retained  for  critical 
command  and  control  traffic  if  needed. 

The  Theatre  Broadcast  System  (TBS)  is  a  military  application  of  commercial  satellite  broadcast 
technology  designed  specifically  for  Australian  Defence  Force  requirements.  It  aims  at 
delivering  data,  audio  and  video  to  many  widely  distributed  users,  by  direct  service  to  stand 
alone  terminals,  and  by  feeding  deployed  communications  systems  such  as  local  data  archives 
and  LANs.  It  relies  on  COTS  hardware,  adapted  to  support  military  grade  encryption,  and  an 
extensive,  custom  software  architecture  designed  for  Australian  military  requirements. 

Broadcast  communication  systems  have  a  number  of  advantages  over  their  full  duplex 
counterparts.  Broadcast  systems  can  simultaneously  service  a  large  number  (hundreds)  of 
receive  terminals  from  a  single  broadcast  hub  using  a  fixed  transponder  bandwidth.  Receive 
terminal  costs  are  generally  much  lower  than  that  required  for  full  duplex  systems,  as 
expensive  transmit  hardware  is  avoided.  In  addition,  terminals  may  receive  transmissions 
whilst  maintaining  local  radio  silence.  Data  required  by  all  receivers  need  only  be  transmitted 
once,  and  the  resultant  efficiency  gain  can  be  enormous  in  many  applications.  By  comparison, 
use  of  full  duplex  links  requires  transponder  bandwidth,  and  therefore  cost,  to  increase  linearly 
with  the  number  of  receivers.  Each  terminal  must  be  capable  of  transmission,  and  it  is  usually 
not  possible  to  maintain  radio  silence  without  breaking  the  reception  path. 

The  prime  disadvantage  of  broadcast  systems  however,  is  that  many  protocols  and  service 
types  (for  example  the  Internet  Transmission  Control  Protocol,  TCP)  cannot  be  supported  over 
one  way  links  because  they  rely  on  an  explicit  return  path.  This  is  a  severe  limitation.  Pure 
broadcast  systems  offer  no  means  for  the  remote  user  to  acknowledge  receipt  of  traffic,  to 
modify  the  broadcast  they  receive,  or  to  request  additional  information.  This  often  precludes 
their  use  for  command  and  control  traffic. 
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Considerable  research  is  currently  being  devoted  to  addressing  these  problems  whilst 
maintaining  the  advantages  of  a  broadcast  environment.  If  a  wide  band  broadcast  is  teamed 
with  a  narrow  band  request  link  or  back-channel,  a  flexible  system  can  be  designed  to  service 
inherently  asymmetric  traffic.  If  the  back-channel  is  connected  permanently,  or  at  least 
occasionally,  many  features  of  the  full  duplex  link  are  regained.  Receipt  of  information  can  be 
acknowledged,  retransmission  of  data  received  in  error  may  be  requested,  the  broadcast  can  be 
customised  by  users  to  suit  local  requirements  and  limited  information  (such  as  simple 
messaging)  transmitted  into  the  hub  station.  Asymmetric  systems  excel  in  situations  where 
upstream  traffic  is  minimal  but  high  downlink  bandwidth  is  required.  These  aspects  are 
summarised  in  Table  1. 

An  example  of  a  modern  asymmetric  communications  system  is  a  Pay-per-View  satellite  TV 
architecture.  Movies  are  received  via  the  broadcast  downlink  at  2  Mbps,  and  a  2400  bps 
telephone  link,  integrated  into  the  set  top  box,  is  used  for  movie  selection,  authentication  and 
billing.  Another  example  is  that  of  "asymmetric  Internet  extension"  over  satellite.  The 
broadcast  downlink  and  phone  back-link  are  connected  to  a  personal  computer  producing  a 
system  which  offers  excellent  web  browsing  performance.  Proxies  direct  the  low  bandwidth 
upstream  traffic  from  the  user  (icon  clicks)  via  the  phone  line,  and  deliver  internet  content  over 
the  broadcast  satellite.  The  TBS  system  is  an  example  of  this  asymmetric  Internet  extension 
technology. 


2.  The  Concept  of  Military  Broadcast 

The  principal  task  of  Theatre  Broadcast  is  to  deliver  situational  awareness  to  deployed  forces 
through  provision  of  high  bandwidth  information  tailored  to  the  specific  requirements  of 
individual  receiving  locations.  Information  resident  in  the  strategic  domain  (Figure  1)  can  be 
transferred  to  users  using  both  PUSH  and  PULL  concepts.  A  strategic  commander  or  broadcast 
manager  can  direct  that  information  products  (video,  audio  or  data)  be  broadcast,  or  PUSHed, 
from  the  broadcast  centre  or  Primary  Injection  Point  (PIP),  to  deployed  users.  This  can  be  done 
on  a  case  by  case  basis,  or  by  an  automated,  repetitive  process.  The  effectiveness  of  this 
approach  is  dependent  on  the  extent  to  which  user  needs  can  be  anticipated,  the  extent  of 
preplanning  and  on  the  judgement  of  strategic  commanders  in  response  to  changed  tactical 
user  requirements.  It  is  clearly  appropriate  for  delivering  situational  awareness  maps  showing 
force  movements  and  locations  for  example,  which  can  be  broadcast  every  few  minutes  to  all 
forces  in  theatre. 

Not  all  needs  can  be  anticipated  however,  and  the  PULL  capability  allows  users  to  request  the 
unplanned  broadcast  of  specific  information  (Figure  1).  The  simplest  PULL  method  uses 
manual  voice  or  email  connectivity  to  Request  Manager  personnel,  over  any  available  links,  to 
request  transmissions.  This  is  time  consuming  and  labour  intensive.  Automated  PULL  concepts 
such  a  web  browsing,  database  retrievals  and  data  mining  are  more  attractive.  Here,  Request 
Link  communications  are  used  to  make  a  data  connection  to  Request  Manager  software  agents 
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Feature 

FDX 

BC 

Asym 

Simultaneous  service  to 
many  receivers 

No 

Yes 

Yes 

Terminal  cost 

High 

Low 

Low 

Radio  silence  possible 
while  receiving 

No 

Yes 

Yes 

Support  TCP 

Yes 

No 

Poss. 

Support  UDP 

Yes 

Yes 

Yes 

Can  acknowledge  receipt 

Yes 

No 

Yes 

Retransmission  of  errored 
packets  possible 

Yes 

No 

Yes 

Upstream  information 
transfer,  e.g.  messaging 

Yes 

No 

Some 

Table  1.  Some  features  of  pure  broadcast  (BC),  full  duplex  (FDX)  and  asymmetric  (Asym) 
communications  systems . 


and  request  broadcast  of  information  from  source  archives  in  real  time.  The  HTTP  (web) 
protocol  is  ideal  for  this  task  as  it  performs  well  over  highly  asymmetric  links  and  is  widely 
implemented  in  commercial  systems.  Many  database  engines  for  example,  support  web  based 
access. 

Information  derived  from  sources  in  the  theatre  can  be  injected  into  the  system  either  by 
trunking  back  to  the  Primary  Injection  Point  (as  shown  in  Figure  1)  or  by  direct  uplink  to  the 
broadcast  satellite.  The  location  managing  these  data  transfers  is  known  as  a  Tactical  Injection 
Point  (TIP).  } 

Information  broadcast  from  the  PIP  is,  in  general,  received  by  all  units.  Security  architectures 
are  an  important  aspect  of  broadcast  systems  in  that  they  are  the  sole  means  of  access  control. 
Conventional  bulk  hardware  encryption  or  software  encryption  schemes  can  provide  separate 
security  compartments.  Flexible  hardware  capable  of  payload  encryption  of  many  simultaneous 
IP  and/or  ATM  streams  is  becoming  increasingly  available. 

The  large  volume  of  information  delivered  by  high  data  rate  broadcast  systems  must  be 
carefully  managed  to  avoid  overload  of  both  users  and  physical  storage  systems.  This  can  be 
achieved  using  a  combination  of  customised  user  profiles  and  intelligent  caching.  Accessing 
information  resident  in  cache  is  very  convenient  for  the  user.  It  is  available  immediately  if 
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required  (no  delay),  request  links  do  not  need  to  be  connected  and  operations  can  proceed 
during  radio  silence.  Alternatively,  the  information  can  be  accessed  at  a  later  time,  for  example 
over  night  broadcast  for  morning  analysis.  Cache  searching  efficiency  can  be  enhanced  by 
provision  of  local  pointers  or  links  broadcast  with  the  information.  A  user  defined  local  profile 
can  specify  the  nature  of  information  which  is  of  interest,  by  location,  keyword,  time,  etc.  All 
received  information  is  initially  cached  by  the  receiver  terminal,  but  after  the  cache  is  filled, 
information  not  matching  the  profile  is  preferentially  discarded.  Eventually,  some  information 
matching  the  profile  may  also  need  to  be  discarded,  again  based  on  specific  criteria.  Large 
caches  (many  gigabytes)  are  desirable. 

This  information  management  regime  is  difficult  to  implement  comprehensively  today.  For 
effective  cache  and  profile  management,  all  information  must  be  tagged  in  a  common  metadata 
format  specifying  attributes  such  as  information  type,  pertinent  location,  expiry  time,  etc.  This 
metadata  is  used  by  management  algorithms  to  implement  the  user  profiles.  Unfortunately,  this 
is  rarely  the  case  in  current  military  data  systems.  Nevertheless,  some  management  control  can 
be  obtained  using  tags  implemented  within  the  broadcast  system  to  represent  different  data 
classes,  concurrent  use  of  differing  metadata  formats  from  different  information  repositories 
and  application  of  simple  principles  such  as  discarding  older  information  first. 


3.  TBS  Hardware  Architecture 


(a)  Transmit  Suite 

The  TBS  hardware  architecture  designed  by  DSTO  Communications  Division  derives  from  that 
used  for  commercial  digital  satellite  TV  (HDTV)  broadcast  and  conforms  to  the  MPEG-2 
(Motion  Picture  Experts  Group)  and  DVB  (Digital  Video  Broadcast)  standards.  While  it  may  be 
possible  to  develop  more  appropriate  devices,  use  of  commercial  standards  offers  inexpensive, 
highly  integrated  components,  the  opportunity  to  field  a  demonstration  system  on  a  short  time 
scale  and  the  possibility  of  integrating  military  information  broadcasts  seamlessly  with 
commercial  TV  broadcasts  should  military  satellites  be  unavailable. 

A  simplified  version  of  the  TBS  transmit  architecture  is  shown  in  Figure  2.  Analogue  video  and 
audio,  either  direct  from  a  camera  and  microphone,  or  trunked  from  another  location,  enter  the 
encoder  and  are  digitised,  compressed  and  framed  into  packets  by  standard  MPEG-2 
algorithms.  Incoming  IP  (UDP)  data  is  converted  into  a  serial  stream  using  a  network  bridge 
("B"  in  the  figure)  and  encoded  into  MPEG-2  packets.  The  encoder  output  consists  of  a  stream 
of  MPEG-2  transport  layer  packets,  some  containing  audio,  some  video  and  some  data 
information.  This  stream  is  then  encrypted  and  passed  to  a  repacketiser,  which  reframes  the 
raw  encrypted  serial  data  into  an  MPEG-2  transport  stream.  Stream  data  from  different  security 
compartments  is  then  combined  in  a  DVB  MUX  before  modulation,  upconversion  and 
uplinking  to  the  satellite  from  the  PIP.  QPSK  modulation  with  a  FEC  comprising  a  rate  % 
Viterbi  code  and  a  204/ 188  Reed  Solomon  code  are  typically  used.  Ku-band  transponders  have 


4 


DSTO-TN-0287 


been  used  for  system  trials  to  date,  however  the  Ka-band  payload  on  the  Optus  Cl  satellite  will 
ultimately  be  used  for  Australian  Defence  high  data  rate  broadcasts. 

(b)  Practical  Details  -  MPEG,  DVB  and  Overhead 

Each  188  byte  MPEG-2  transport  stream  packet  incorporates  a  4  byte  header  containing  the 
important  Program  Identifier  (PID)  information,  which  identifies  each  packet  as  containing 
data  from  a  particular  information  stream.  For  example,  the  video  data  for  a  TV  program  and 
the  corresponding  English  and  Spanish  audio  data  would  each  have  different  PID  values.  IP 
data  is  likewise  encoded  with  a  specific  PID.  The  MPEG  encoders  used  in  the  system  described 
here  are  each  capable  of  simultaneously  encoding:  a  video  program  at  compressed  output  rates 
up  to  8.2  Mbps,  four  audio  channels  at  compressed  output  rates  up  to  256  kbps  (usually  used  as 
two  stereo  pairs),  a  high  bit  rate  data  stream  at  input  rates  up  to  10  Mbps  and  a  low  bit  rate  data 
stream  at  rates  up  to  57,600  bps.  The  low  bit  rate  data  is  used  commercially  to  provide  teletext 
service  onto  the  video  picture. 

Additional  MPEG-2  transport  stream  packets  containing  program  associations  (a  list  of  all 
programs  in  the  stream),  program  maps  (specifying  which  audio  or  teletext  PIDs  associate  with 
which  video  PIDs),  and  conditional  access  tables  (commercial  encryption)  are  also  produced  by 
the  encoder.  Further  packets  may  optionally  be  produced  giving  physical  system  configuration 
information,  service  descriptions  (names  of  networks  and  providers),  groups  of  services, 
running  status  (whether  or  not  a  particular  event  is  in  progress)  and  current  time  and  date.  The 
format  of  these  additional  tables  is  specified  by  the  Digital  Video  Broadcast  (DVB)  standard. 

It  can  be  shown  that  the  total  output  data  rate  of  the  MPEG-2  encoder  is  given  by: 

188 

OutputRate  =  (Video  +  160xP/c) 

188  /  x 
+—(Aud,°) 

188 

+  —({LSD  +  HSD)x  1.01) 

+  PAT  +  PMT  +  PCR 
+  DVB 

where  Video,  Audio,  LSD  and  HSD  are  the  data  rates  assigned  to  the  video,  audio,  low  speed 
data  and  high  speed  data  services  respectively;  Pic  is  the  video  picture  (frame)  rate;  PAT,  PMT 
and  PCR  are  the  MPEG-2  tables  referred  to  above;  and  DVB  represents  the  optional  DVB  tables. 
The  factor  188/184  represents  the  packet  header  overhead. 


Assuming  no  DVB  tables  are  transmitted,  as  is  the  case  for  TBS,  the  resultant  overhead  is 
primarily  a  result  of  the  PAT  +  PMT  +  PCR  term,  which  evaluates  to  approximately  135  kbps. 
This  represents  a  minor  fractional  overhead  at  the  usual  operating  rates  of  >2  Mbps,  however  it 
can  become  significant  if  low  output  rates  are  used. 
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Information 

Sources 


Figure  1.  The  concept  of  Theatre  Broadcast  involves  both  command  PUSH  of  information  to 
users  over  the  broadcast  link  and  user  PULL  of  information  from  strategic  archives  using 
request  links. 


Video  Audio  IP  Data 


Uplink 


Figure  2.  The  Theatre  Broadcast  transmit  architecture  maintains  compatibility  with 
commercial  MPEG-2/DVB  systems  whilst  implementing  military  grade  security.  To  date 
only  a  single  compartment  has  been  constructed. 


IP  Data  Video  Audio 


Any  compartment 


Figure  3.  The  Theatre  Broadcast  receive  architecture  makes  use  of  compact,  inexpensive 
Integrated  Receiver  Decoders  The  equipment  can  receive  any  compartment  which  can  be 
decrypted. 
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(c)  Receive  Hardware 

The  receive  architecture  uses  a  0.6  metre  diameter  dish  feeding  an  LNB  (low  noise 
block  down  converter)  which  down-converts  the  signal  from  Ku-band  to  an  L-band 
intermediate  frequency  (Figure  3).  The  IF  is  then  fed  to  an  Integrated  Receiver 
Decoder  (IRD)  which  demodulates  the  signal,  performs  error  correction,  and 
decodes  the  MPEG-2  transport  stream,  outputting  the  packet  payloads  as  a  serial 
data  stream.  The  decoder  is  configured  to  output  data  corresponding  to  the  PID  of 
the  security  compartment  desired.  The  data  is  then  decrypted  and  input  to  a  second 
IRD  which  is  configured  to  perform  the  MPEG  decode  function  only;  the  receiver 
and  demodulator  functions  are  disabled.  Analog  video  and  audio  are  output  directly 
to  display  devices  and  speakers,  and  serial  data  converted  to  IP  packets  using  a 
network  bridge.  A  ruggedised  notebook  computer  running  Windows  NT  is  typically 
used  as  the  receive  client,  receiving  the  broadcast  on  an  IP  interface,  other  LAN 
based  hosts  accessing  broadcast  information  resident  on  this  computer  via  a  second 
IP  interface.  Alternatively,  the  broadcast  can  be  routed  directly  onto  a  local  LAN. 

The  current  TBS  compact,  transportable  receive  suite  configuration  is  packaged  in 
two  waterproof  cases  80x70x38  cm  and  80x55x70  cm,  which  includes  (IRDs),  the 
dish,  cabling,  Mobilesat  request  link  hardware,  a  small  TV,  a  printer,  and  other 
accessories  (Figures  4  and  5). 

(d)  Request  Links 

Request  links  are  best  matched  to  the  requirements  of  the  deployment.  Some 
deployments  need  voice  links  only,  some  require  minimal  data  links  to  be  connected 
occasionally,  and  others  require  medium  data  rate  permanent  connections.  Some 
practical  request  link  classes  are  shown  in  Table  2.  Voice  connectivity  represents  the 
minimal,  non-automated  link  to  the  broadcast  centre  allowing  manual  requests  to  be 
made  of  manning  staff.  Automated  request  links  are  implemented  via  an  IP  interface 
(either  direct  or  through  a  encrypted  serial  port)  on  the  receive  client.  Any 
communications  medium  capable  of  supporting  TCP  is  satisfactory.  The  most 
technically  interesting  request  link  category  is  that  of  data  services  carried  on 
commercial  voice  networks.  These  include  terrestrial  PSTN,  GSM  and  CDMA  as  well 
as  LEO  and  GEO  satellite  networks  such  as  Iridium,  Mobilesat,  DMCN,  Globalstar, 
ICO,  etc.  While  these  networks  are  designed  and  marketed  for  voice,  they  all  support 
data  connections  at  various  rates  in  the  2.4-16  kbps  range.  In  the  future,  such  services 
will  be  ubiquitous  and  inexpensive.  Security  solutions  which  dispense  with  external 


Request  Link  Category 

Typical  BW 

Voice  (manual) 

3  kHz 

Data  on  commercial  voice  network 

2.4-16  kbps 

Transmit  to  broadcast  satellite 

64  kbps 

Trunked  data  network 

>1  Mbps 

Table  2.  Typical  request  links  used  in  the  TBS  system. 
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Figure  4.  The  standard  TBS  compact  receive  suite  configuration  uses  a  0.6  m  dish,  a  small 
electronics  rack  and  a  laptop  computer. 


Figure  5.  TBS  standard  receive  suite  packaging  consists  of  txvo  ruggedised  containers,  the 
receive  electronics  (centre  front)  and  the  accessories  box  (centre  rear). 
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hardware  cryptos  are  under  development.  Because  of  these  inherent  advantages, 
they  have  received  the  most  attention  in  the  development  of  request  links  for  TBS, 
and  specific  hardware  interfaces  developed  for  PSTN,  GSM  and  Optus  Mobilesat. 
Enhanced  request  channels  are  implemented  for  larger  platforms  such  as  ships  by 
creating  an  additional  full  duplex  link  to  the  PIP  through  the  broadcast  satellite  with 
the  same  dish  used  to  receive  the  downlink.  This  typically  requires  increasing  the 
dish  size  from  the  standard  0.6  m  to  approximately  1.2  m  diameter  (at  Ku-band)  to 
avoid  spillover  onto  adjacent  satellites.  A  64  kbps  request  link  is  typically  used. 
Finally,  trunked,  secured  data  networks,  implemented  via  fixed  line  or  satellite,  often 
exist  at  major  installations  such  as  deployed  headquarters  or  fixed  bases.  These  can 
be  used  directly  as  TBS  request  links. 


4.  Software  Architecture 

(a)  TBS  File  Delivery 

The  TBS  software  architecture  consists  of  software  applications  running  on  a 
scheduled  file  delivery  service.  The  applications  perform  user  driven  tasks  such  as 
email,  web  browsing,  etc,  while  the  delivery  service  provides  the  connectivity 
required  to  transparently  support  the  applications.  Reliable  file  delivery  can  be 
attempted  if  request  links  are  connected,  either  in  real  or  delayed  time. 

File  delivery  over  a  broadcast  system  differs  from  file  delivery  over  a  conventional 
network  in  two  principal  ways:  data  is  delivered  simultaneously  to  multiple 
recipients  and  the  return  path  may  be  absent.  The  Internet  Protocol  (IP)  incorporates 
a  multicast  mechanism,  which  directs  IP  Datagram  traffic  to  specified  users.  IP 
multicast  is  used  by  TBS  for  data  transmissions  over  the  broadcast  channel.  Multicast 
offers  the  opportunity  to  screen  traffic  from  users  or  target  specific  users  via  their  IP 
address,  although  this  feature  has  not  been  used  to  date.  The  standard  TCP  protocol 
requires  a  full  duplex  path  along  which  to  acknowledge  received  packets  and  to 
request  retransmission  of  packets  received  in  error.  In  contrast,  the  User  Datagram 
Protocol  (UDP),  a  connectionless  protocol  which  makes  no  attempt  to  establish  a 
path  to  the  sender,  sends  no  replies  and  no  requests  for  retransmission  is  a  natural 
choice  for  broadcast  systems. 

To  address  the  issue  of  errored  transmissions  within  the  TBS  architecture  DSTO 
developed  a  flexible,  proprietary  file  transmission  protocol,  known  as 
MUSTAFA.MUSTAFA  supports  UDP/IP  multicast  to  transmit  files  at  bandwidths 
specified  by  a  real  time  adaptive  scheduler  known  as  RATS.  The  MUSTAFA  server 
process  breaks  data  files  into  appropriately  sized  packets  and  multicasts  them  over 
the  broadcast  channel  to  client  MUSTAFA  processes  which  reconstruct  the  file  onto 
the  host's  file  system  (Figure  6).  The  MUSTAFA  program  attempts  reliable  file 
delivery  in  the  presence  of  channel  errors  through  a  three  pronged  strategy.  First, 
multiple  transmissions  of  each  file  are  made,  which  allows  packet-wise  file 
reassembly  by  the  receive  clients,  except  if  a  particular  packet  is  errored  in  all 
transmissions.  Two  file  transmissions  are  usually  used.  Second,  if  a  back  link  is 
currently  available,  MUSTAFA  can  accept  packet  acknowledgements  allowing 
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Figure  6.  Scliematic  operation  of  the  TBS  file  transfer  process. 


errored  packets  to  be  immediately  scheduled  for  retransmission.  Hosts  without 
connected  back  links  benefit  from  retransmissions  requested  by  others  if 
corresponding  corruptions  have  occurred.  Thirdly,  an  additional  feature  known  as 
"Delayed  Gratification",  allows  errored  packets  from  large  files  to  be  retransmitted 
when  a  back  link  is  reconnected  at  a  later  time  (possibly  days  later)  and  file 
reassembly  on  the  client  completed.  This  procedure  was  found  desirable  to  improve 
service  to  files  in  the  100MB-1GB  size  range.  The  effectiveness  of  this  latter  strategy 
is  largely  dependent  on  the  availability  of  cache  space  at  the  client.  In  addition, 
MUSTAFA  can  transmit  IP  streams  (as  opposed  to  files)  at  specific  data  rates,  and  is 
able  to  control  the  stream  transmission  rates.  MUSTAFA  can  notify  stream  sources  to 
change  their  output  data  rate,  assuming  flexible  source  encoding  is  available. 

The  RATS  scheduler  optimizes  use  of  the  broadcast  channel  by  calculating  the 
bandwidth  to  be  applied  to  all  current  broadcast  requests,  forming  a  schedule,  and 
controlling  multiple,  simultaneous  transfer  processes  within  MUSTAFA  in  real  time. 
In  addition,  requests  for  retransmission  of  errored  packets  from  multiple  users  are 
fielded,  processed  and  the  packets  added  to  the  schedule.  The  scheduler's  algorithm 
processes  three  priority  metrics  supplied  for  each  request,  to  determine  a  mix  of 
concurrent  broadcast  items  which  delivers  the  maximum  military  value  at  a  given 
instant  of  time.  These  are  the  military  priority  class  of  the  traffic  which  determines 
the  time  in  which  the  data  must  be  delivered,  the  user  perceived  value  of  the  request 
and  the  action  requested  if  RATS  is  unable  to  satisfy  the  request  in  the  time 
specified.  The  latter  comprises  three  options,  discard  the  request,  proceed  with 
transmission  if  the  data  is  not  going  to  be  "too"  late  and  transmit  regardless  of 
arrival  time. 
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The  concepts  behind  and  operation  of  the  RATS  algorithm  are  complex,  and  are 
discussed  elsewhere.  All  access  to  the  broadcast  channel  is  negotiated  through  the 
scheduler  by  lodging  a  request.  Each  request  specifies  the  user's  requirement  (file  to 
be  transmitted),  authentication  details  of  the  requester,  and  the  desired  scheduling 
parameters.  The  scheduler  determines  if  the  request  is  to  be  serviced  immediately, 
and  if  so  submits  the  job  to  MUSTAFA  specifying  the  bandwidth  allocation.  The 
schedule  is  constantly  recalculated  (approximately  every  second,  according  to  a 
configuration  parameter)  to  take  account  of  delivery  progress  on  existing  jobs  and 
newly  received  requests,  and  the  results  forwarded  to  MUSTAFA  for 
implementation.  The  effective  bandwidth  of  any  broadcast  job  is  constantly  adjusted 
to  meet  the  optimization  objective. 

The  system  described  is  superior  to  simple  scheduling  queues  in  that  the  military 
value  delivered  (judged  by  the  definition  used)  remains  high,  even  under  severe 
system  overload  conditions.  This  is  considered  important  in  the  Australian  context, 
where  limited  satellite  resources,  lower  data  rates  and  smaller  dishes  are  expected, 
than  for  example,  is  the  case  with  the  US  GBS  system. 

Typical  hardware  required  at  the  broadcast  centre  consists  of  a  Sun  workstation 
running  the  RATS  scheduler  and  a  high  end  PC  running  Windows  NT  supporting 
MUSTAFA.  This  machine  also  runs  the  server  components  of  many  of  the  delivery 
applications  discussed  below. 


(b)  Application  Delivery  over  TBS 

(i)  Automated  File  Delivery 


The  most  fundamental  application  running  over  TBS  is  the  TBS  PUSH  Service,  which 
offers  automated,  periodic  retransmission  of  specified  information.  New  information 
is  continually  becoming  available  at  the  broadcast  centre,  and  this  service  is  used  to 
ensure  that  data  in  the  receive  terminals  is  constantly  updated  to  accurately  reflect 
that  at  the  server. 

Primary  uses  of  the  service  are  to  deliver  rapidly  changing  information  such  as  track 
data  and  mail  databases,  and  to  download  large  numbers  of  associated  files  such  as 
archive  directories  or  web  site  mirrors.  Critical  system  configuration  parameters 
required  by  all  receivers  are  also  transmitted  automatically.  Automated  updates 
require  no  action  by  users,  and  can  be  delivered  overnight  or  during  down  time 
between  operations,  in  the  absence  of  receiver  manning  personnel.  Repeated 
transmissions  also  allow  terminals  which  have  been  out  of  service  due  to  shutdowns 
for  transportation,  hardware  failures,  or  have  been  out  of  the  satellite  coverage  area, 
to  be  rapidly  and  automatically  updated  upon  requiring  the  system.  Multiple 
transmissions  also  maximise  the  chance  of  information  delivery  in  the  presence  of 
channel  errors  and  jamming.  A  graphical  user  interface  to  the  program  allows  a 
broadcast  manager  to  specify  files  and  directories  grouped  into  logical  categories 
having  common  characteristics,  for  example  news,  email,  etc.  Each  category  has 
associated  update  periods,  priority  characteristics,  selective  enable  or  disable 
parameters,  and  transmission  repeats. 
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Web  Servers 


Figure  7.  Schematic  operation  of  the  TBS  web  proxies. 


(ii)  Web  Browsing 


There  is  an  increasing  focus  on  web  based  systems  for  commercial  information 
delivery  and  this  is  flowing  through  to  military  information  systems.  Also,  many 
archives,  databases,  and  image  presentation  packages,  which  were  created  with 
custom  user  interfaces,  are  implementing  web  front  ends  to  facilitate  network  access 
and  reduce  user  training  requirements. 

Conventional  access  to  web  servers  requires  a  full  duplex  connection,  which  is  not 
available  on  TBS.  In  cases  where  a  web  site  is  of  significant  importance  to  users,  the 
entire  site,  or  appropriate  subsections,  can  be  broadcast  to  the  clients  and  served 
locally  by  the  receive  terminal  web  server.  Commercial  mirroring  software  and  the 
automated  TBS  PUSH  Service  are  used. 

The  TBS  Web  Proxy  Service  (Figure  7)  was  developed  to  provide  an  interactive  web 
browsing  facility  assuming  a  narrow  band  request  channel  is  available.  The  service 
incorporates  a  client  proxy  at  the  deployed  receive  site  to  terminate  the  user's 
browser  connections  and  a  server  proxy  at  the  broadcast  centre,  which  connects  to 
web  servers  in  the  strategic  network  to  fulfil  browsing  requests.  In  operation,  the 
user  activates  a  link  on  a  web  page  and  the  user's  browser  makes  a  connection  to  the 
client  proxy  which  in  turn  transmits  a  request  for  the  appropriate  web  page  to  the 
server  proxy  via  the  request  link.  The  client  proxy  attaches  user  details  and 
scheduling  priorities  to  the  request.  On  receiving  the  client  request,  the  server  proxy 
retains  the  user  details  and  establishes  a  connection  with  the  target  web  server  to 
retrieve  the  requested  page.  The  response  is  stored  in  a  server  cache  and  a  request 
issued  to  the  scheduler,  coupled  with  the  user's  details  and  parameters  provided 
with  the  original  request.  The  file  is  transmitted  by  MUSTAFA  under  scheduler 
control  and  the  client  proxy  delivers  the  response  to  the  browser.  The  received  file  is 
also  stored  in  local  cache  on  the  receive  client.  This  series  of  operations  is  transparent 
to  the  user  and  appears  only  marginally  slower  than  a  fast  fixed  internet  connection 
at  light  system  loads.  Loaded  browsing  performance  is  dependent  on  allocated 
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priorities  and  delivery  times,  but  the  TBS  scheduler  is  given  considerable  license  to 
attempt  to  deliver  interactive  services  such  as  web  browsing  promptly,  at  the 
expense  of  automated  downloads  and  other  non  interactive  services.  Maximal  use  is 
made  of  both  server  and  client  caching  in  an  attempt  to  improve  performance. 

LAN  based  hosts  at  the  receive  site  obtain  web  services  by  proxying  their  browsers 
to  the  TBS  client.  Requests  from  many  users  can  be  handled  simultaneously.  Users 
specify  browsing  parameters  such  as  user  name,  password  and  scheduling  priorities 
via  a  special  browser  window,  known  as  the  Minder  Panel,  implemented  with  a 
custom  Java  applet.  The  applet  makes  a  connection  to  a  client  proxy  to  register  users 
and  their  priority  settings.  The  Minder  Panel  also  makes  a  connection  to  a  Client 
Manager  software  application  to  facilitate  status  reporting  and  system  alerts. 


(iii)  E-mail 


The  TBS  mail  system  is  currently  a  commercial  standard  SMTP/ POP3  system  with 
directory  replication  over  TBS.  This  could  be  replaced  by  a  more  secure  X400  or 
Lotus  Notes  based  system  if  desired. 

SMTP  server,  client  and  POP  server  processes  are  run  on  a  mail  host  at  the  broadcast 
centre.  This  handles  all  mail  entering  and  leaving  the  TBS  system  from  other 
networks.  All  management  of  user  accounts  and  passwords  is  done  from  this  central 
facility.  Each  deployed  TBS  receive  client,  runs  similar  POP  and  SMTP  processes. 

To  provide  downward  mail  service  from  the  strategic  domain  to  deployed  users,  the 
POP  mail  directories  of  the  mail  host  are  automatically  broadcast  by  the  TBS  PUSH 
service.  Usually,  three  or  five  minute  updates  are  specified.  Local  users  on  a 
deployed  LAN  use  a  POP  client  such  as  Microsoft  Outlook  to  automatically  check 
their  mailbox  as  often  as  desired.  Because  of  the  high  downlink  bandwidth  available, 
mails  with  attachments  hundreds  of  megabytes  in  size  are  easily  handled. 

To  provide  upward  service,  mail  directed  from  deployed  user  mail  clients  is  passed 
via  SMTP  to  the  SMTP  server  on  the  TBS  Receive  Client  computer.  If  a  TBS  request 
link  is  currently  connected,  the  deployed  SMTP  server  immediately  forwards  the 
mail  up  to  the  SMTP  client  at  the  broadcast  centre.  If  not,  it  queues  the  mail,  polls 
every  one  minute  for  a  request  link  connection,  and  forwards  queued  mail  when 
possible.  Actual  mail  capability  from  the  deployed  to  the  strategic  domain  is 
dependent  on  the  request  links  used.  Trials  have  shown  that  mail  sizes  of  100  kB  are 
a  reasonable  practical  limit  using  2400  bps  Optus  Mobilesat  request  links. 

This  mail  system  has  an  important  advantage  over  a  simpler,  conventional,  ISP  style, 
pure  POP  system  operated  from  the  broadcast  centre.  It  allows  deployed  users  on  a 
local  area  network  to  send  mail  in  the  absence  of  a  TBS  request  link.  The  mail  passes 
only  as  far  as  the  receive  client  until  a  request  link  is  connected,  but  there  is  no 
requirement  on  distributed  users  to  know  when  request  links  are  operating,  and  the 
user  is  shielded  from  error  messages  resulting  from  attempting  to  send  mail  over 
nonexistent  links. 
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(iii)  Cheetah  File  Manager 


In  some  cases,  custom  proxy  interfaces  incorporating  additional  functionality  are 
required  to  service  existing  information  systems  over  TBS.  The  example  described 
here  is  that  of  the  Cheetah  map  display  application  developed  by  Australian  Defence 
Industries.  This  software  places  icons  representing  the  locations  of  forces,  platforms, 
military  assets,  etc,  on  a  map  background,  and  continually  updates  the  display  in 
real  time  from  information  supplied  in  small  standard  messages  continually  received 
from  a  Cheetah  server. 

The  message  service  is  usually  provided  to  clients  over  narrow  band  serial  links.  To 
offer  an  improved  Cheetah  service  over  TBS,  a  Cheetah  File  Manager  application 
was  developed  (Figure  8).  A  Cheetah  server  is  configured  to  receive  the  message 
stream  at  the  broadcast  centre  and  output  concatenated  message  data  to  a  file.  The 
Cheetah  File  Manager  service  reads  this  file  and  scans  for  updated  tracks,  storing 
these  in  a  data  base  with  associated  date/time  information.  This  database  is  used  to 
periodically  build  a  new  output  file  containing  details  of  the  tracks  which  have  been 
updated  in  a  specified  period.  The  application  then  automatically  requests  the  TBS 
scheduler  to  deliver  this  file  to  clients  over  the  broadcast.  An  update  period  of  a  few 
minutes  is  used.  The  file  is  automatically  ingested  by  the  deployed  Cheetah  client 
displaying  the  latest  information.  Field  deployed  terminals  can  thus  obtain  a 
complete  picture  immediately  after  switch  on,  rather  than  waiting  for  progressive 
delivery  of  a  picture  over  narrow  band  links. 


Cheetah  Feed 


Figure  8.  Schematic  operation  of  Cheetah  support  over  TBS 
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5.  US  GBS  and  Interoperability 


The  impetus  for  an  Australian  theatre  broadcast  system  arose  both  from  commercial 
developments  and  from  similar  developments  in  the  US  Department  of  Defense.  In 
1994  the  US  implemented  the  Joint  Broadcast  Service,  which  provided  service  to  US 
forces  deployed  in  the  European  theatre  until  1999.  Due  to  the  success  of  this  interim 
service,  a  Phase  II  program  known  as  the  Global  Broadcast  System  (GBS)  was 
pursued,  with  Raytheon  Co  as  prime  contractor.  Fielding  of  the  GBS  system  has 
commenced  in  the  Pacific  Theatre,  although  the  system  is  still  undergoing  significant 
developmental  changes. 

The  UK  is  currently  in  the  process  of  defining  a  Direct  Broadcast  System  (DBS)  and 
building  a  demonstration  system.  The  form  DBS  this  will  take  has  not  been  finalised. 

Any  decision  to  proceed  with  indigenous  developments  rather  than  purchase 
systems  developed  overseas  involves  considerations  of  interoperability,  the  extent  to 
which  the  systems  can  be  tailored  to  meet  Australian  requirements,  sovereignty, 
access  to  system  code,  cost,  logistics,  Australian  industry  support,  etc.  At  this  stage, 
no  decision  has  been  made  on  what  path  should  be  taken  towards  a  fully  operational 
Australian  high  data  rate  broadcast  capability.  Allied  interoperability  remains 
however,  an  important  concern  for  all  Australian  military  communications,  with  the 
goal  of  seamless  exchange  of  releasable  information  among  all  parties.  Different 
degrees  of  interoperability  may  be  achieved  by  a  number  of  different  approaches. 

Direct  reception  of  an  allied  channel  or  security  compartment  from  the  US  GBS 
broadcast  satellites  would  almost  certainly  require  US  GBS  equipment  supplied  by 
the  US  contractor.  It  is  unlikely  that  sufficient  hardware  and  software  specifications 
could  be  obtained  to  build  a  compatible  system  in  the  absence  of  a  procurement. 
Procurement  of  a  US  GBS  type  transmit  system  and  US  receive  technology  would 
allow  creation  of  a  Australian  GBS-like  system  using  an  Australian  broadcast 
satellite.  This  may  allow  Australian  forces  to  receive  an  allied  channel  from  US 
satellites  when  appropriate.  This  would  be  possible  only  if  the  differences  between 
the  Australian  and  US  GBS  systems  remained  minimal.  Some  differences  would  be 
inevitable,  due  to  differences  between  the  Australian  and  US  broadcast  satellites, 
hardware  and  software  upgrade  schedules  in  both  countries  and  differences  in  the 
system  configuration  Australia  may  adopt  to  support  local  requirements.  Reception 
of  the  allied  channel  would  occur  at  the  expense  of  losing  connectivity  with  the 
Australian  system  unless  the  allied  channel  was  rebroadcast  on  the  Australian 
satellite. 

If  a  technology  similar  to  the  current  DSTO  developed  TBS  demonstration  system  is 
pursued,  interoperability  could  be  achieved  by  strategic  exchange  of  releasable 
information  using  land  line  communications  between  the  US  and  Australian  PIPs, 
and  uplinking  the  allied  channel  on  both  broadcast  systems.  Australian  receivers 
would  be  unable  to  receive  from  the  US  GBS  satellites  and  interoperability  would  be 
limited  to  the  field  of  view  of  the  Australian  satellite  unless  additional  commercial 
satellite  bandwidth  was  procured. 
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6.  Capability  Enhancement  with  TBS 


There  are  a  number  of  significant  challenges  to  be  addressed  if  concrete  capability 
enhancement  is  to  result  from  application  of  high  bandwidth  information  delivery 
systems  in  the  Australian  military  environment.  The  effectiveness  of  such  systems  is 
critically  reliant  on  information  management  infrastructure,  in  both  strategic  and 
deployed  environments. 

An  integrated  management  approach  needs  to  be  developed  in  which  broadcast  or 
asymmetric  technologies  seamlessly  integrate  with  available  full  duplex  and  low 
bandwidth  communications.  This  is  currently  lacking.  It  should  be  possible  for 
example,  for  automated  agents  to  make  decisions  on  the  delivery  paths  for 
information,  and  appropriate  bandwidth  allocated  for  transmission.  This  requires  an 
extensive  metadata  framework.  Middleware  management  layers  that  perform  some 
of  these  functions  are  under  development  by  other  agencies  within  the  ADO  and 
middleware  interfaces  have  been  developed  for  the  TBS  system  by  the  EXC3ITE 
project.  These  interfaces  enable  applications  resident  elsewhere  in  the  strategic 
network  to  communicate  with  the  TBS  scheduler  and  arrange  for  broadcast  of  traffic. 
Using  this  approach  it  should  be  possible  to  radically  improve  delivery  effectiveness 
£qj*  existing  mail  systems,  responses  to  database  queries  and  image  libraries  for 

example. 

The  TBS  system  attempts  to  address  quality  of  service  issues  though  prioritisation  of 
traffic  and  adherence  to  delivery  deadlines,  etc,  but  is  only  partially  effective  in 
delivering  timely  services  to  deployed  users  due  to  the  lack  of  similar  principles  in 
the  wider  strategic  network.  Network  wide,  enterprise  driven  policies  that  can  affect 
and  enforce  end-to-end  military  value  by  maximising  military  value  on  all  links 
within  the  network  need  to  be  developed. 

Organisational  challenges  are  also  created  by  widespread  access  to  strategic 
information  resources.  Existing  command  and  control  structures  often  assume 
information  is  passed  sequentially  down  the  chain  of  command,  and  vetted  at  every 
stage,  rather  than  pulled  directly  by  the  end  user,  bypassing  the  command  chain. 
High  bandwidth  access  has  not  been  widely  available  in  the  past,  so  this  issue  has 
not  been  adequately  addressed.  One  of  the  ways  of  restricting  unfettered  access  is  to 
prepare  information  support  packages  tailored  to  the  requirements  of  specific  users. 
These  can  be  broadcast  (PUSHed)  or  users  granted  permission  to  selectively  PULL 
parts  of  them  from  the  deployed  domain.  Tailored  support  packages  also  offer 
greater  capability  enhancement  to  users  who  are  unable  or  unwilling  to  use  request 
links  frequently.  The  drawback  is  the  considerable  manpower  required  on  the 
strategic  side  for  package  preparation  and  management  and  the  difficulty  of 
predicting  information  requirements  in  advance. 

There  are  always  new  issues  to  be  addressed  in  deploying  any  new  military 
technology.  Theatre  Broadcast  is  no  exception.  However  it  is  likely  that  the 
advantages  offered  by  a  cost  effective,  scalable,  high  data  rate,  information  delivery 
service,  and  the  prospect  of  its  integration  with  information  management 
applications,  will  be  sufficiently  attractive  to  ensure  its  ongoing  use  and  further 
development. 
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